home *** CD-ROM | disk | FTP | other *** search
- Path: pathway1.pathcom.com!ts5l5
- From: insystem@pathcom.com (Geoffrey Welsh)
- Newsgroups: comp.dcom.modems
- Subject: Re: My test results for USR Sportster 33.6kbps
- Date: 18 Feb 1996 17:45:39 GMT
- Organization: InSystems Technologies Inc.
- Message-ID: <4g7ok3$74j@pathway1.pathcom.com>
- References: <4fv36j$lvj@news.flinet.com>
- NNTP-Posting-Host: ts5l5.pathcom.com
- X-Newsreader: News Xpress Version 1.0 Beta #4
-
- In article <4fv36j$lvj@news.flinet.com>, kristof@flinet.com wrote:
- >I tried to evaluate the performance of the USR Sportster 28.8 V.34
- >with 33.6kbps upgrade (purchased recently for just under $200).
- >Just to check how much this new 33.6kbps V.34bis effort is worth in
- >the reality of US residential analog lines.
-
- It's wonderful that you did this, but one of your comments reveals that you're
- not very familiar with the stuff that you're testing. This doesn't make the
- test invalid; after all, you don't have to be a mechanic to test drive a car!
-
- >I used 120MHz and 75Mhz Pentium PC's, each with internal USR.
- >All transfers were done with the popular QuickLink II communication
- >program included with USR and many other modems on the market.
- >The port setting in QuickLink was 115,200-8-N-1, RTS/CTS in both PC's.
- >The modems init strings was just ATZ4, i.e. the normal hardware profile.
-
- Well, QuickLink is only popular because several manufacturers give it away.
- Nothing wrong with that, I just had to get my 2 cents in...
-
- >[...] However, for some strange reason, disabling ARQ LAPM
- >degraded the throughput by about 15-20%. Consequently, all test cases
- >used ARQ/LAPM/V.42bis.
-
- LAP-M (the primary error correction protocol in V.42) and MNP service class 3
- do not send start and stop bits because they are unnecessary when the data is
- transmitted using a synchronous carrier and protected by a CRC. In theory,
- this should boost throughput by 25%, since you're dividing the carrier speed
- by 8 in stead of 10... however, the error correction protocol does have some
- overhead, so the gain is less than 25%... about 19%, assuming no retransmits.
-
- >[...] However, I tried to spend some time looking
- >into the compressing capabilities of V.42bis and compare with
- >the DOS utilities like COMPRESS, PKZIP, or LHA. V.42bis could not
- >match PKZIP or LHA, but it was better than COMPRESS (from Microsoft).
-
- Keep in mind that V.42bis has many limitations: it must be 'instant'; it must
- run in very little ROM and RAM; it must run on a relatively feeble CPU; it
- cannot change its mind on what it's going to do and go back.
-
- >Some very redundant files were compressed so much that the
- >serial port rate 115,200 bps was a bottleneck and was slowing the
- >modem transmission considerably.
-
- Yep... as I've pointed out recently, for a demonstration of V.42bis'
- effectiveness on ridiculously compressable data, lock your serial port to
- 115200 bps, lock your carrier to 1200 bps, and send ten megabytes of nulls.
-
- >[...] All the files I tested with were
- >1MB, i.e. the transfer times were at least 4-5 mins.
-
- This is very good, and very important. Also, I hope you used the _recevier's_
- CPS rate, not the transmitter's.
-
- >All initial connects were 33,600 on both sides. After each file
- >transfer, the ATI6 displayed 33,600/33,600 on both sides.
- >
- >The real/effective throughput (again V.42bis was not able to compress)
- > ZMODEM 31,550 bps
- > ASCII 31,870 bps
-
- You mean, 3155 and 3187 CPS? That's _not_ impressive. Between two Courier
- 33.6 modems I've seen ZedZap CPS rates in the 3800 range. They're rare, but
- they do happen from time to time.
-
- Geoffrey Welsh, Developer, InSystems Technologies Inc.: insystem@pathcom.com
- At home: geoff@zswamp.uucp, [xenitec.on.ca|m2xenix.psg.com]!zswamp!geoff
-